Las palabras de moda no son algo que esperaba cuando comencé mi carrera. En aquellos días, la mayoría de las noticias sobre tecnología llegaban en publicaciones semanales en papel como InformationWeek y Network World. Recuerdo haber pensado para mis adentros: "Hombre, están usando estas mismas palabras una y otra vez cada semana".  Eso se tradujo en personas que usaban palabras de moda... todo el tiempo. En aquel entonces, mis dos palabras de moda favoritas eran las referencias a Internet como la "red mundial" y la "autopista de la información". Siempre me pregunté si habría una súper autopista en algún momento.  Sin embargo, recientemente, noté que las palabras de moda se usan como marcadores de posición donde no tienen mucho sentido. Términos como microservicios, arquitectura basada en eventos, IA y ML se usan en contextos que me llevan a concluir que muchas personas no los entienden del todo. Yo tampoco me esperaba esto…  Imagina esta simple conversación relacionada con una pregunta mal entendida:    ¿A qué hora sale tu vuelo? Persona #1:    A finales de este año. Persona #2:  Si bien la Persona n.º 2 proporciona una respuesta que no es incorrecta, la respuesta realmente no aporta ningún valor a la consulta de la Persona n.º 1.  En esa misma línea, la búsqueda para migrar a microservicios ha enfrentado desafíos similares. La mayoría de las veces, he trabajado con clientes y corporaciones cuyo diseño de "microservicio" dio como resultado un único monoservicio. Básicamente, se reemplazó una aplicación monolítica con una API RESTful realmente grande.  Para esta publicación, pensé que sería divertido analizar un ejemplo de cómo crear un diseño de microservicio orientado a un propósito... de la manera correcta.  El diseño de microservicios orientado al propósito  Un microservicio orientado a un propósito es un servicio que puede valerse por sí mismo y puede incluir un almacén de persistencia dedicado cuando sea necesario. Al estar orientado a un propósito, el microservicio proporcionará un conjunto específico de información y será el sistema de registro de los datos que se rigen dentro de las API asociadas.  Al adoptar el enfoque de microservicio orientado a un propósito, los usuarios pueden agregar nodos adicionales y reducir los nodos existentes para satisfacer las necesidades de la API en ese momento.  Por ejemplo, un microservicio orientado a un propósito centrado en un aspecto de los impuestos sobre la renta puede experimentar el mayor uso durante la primera parte del año y requerir menos instancias en ejecución en la segunda mitad.  Centrémonos en la creación de un diseño de microservicio orientado a un propósito usando un ejemplo muy simple.  Creación de un microservicio basado en Docker  los  es un sistema de cuadrícula utilizado para pronosticar el sexo de un bebé al nacer. Esto se hace proporcionando el mes de la concepción y la edad actual de la madre en el momento de la concepción.   Predictor de género chino   Se rumorea que la familia imperial de la dinastía Qing se basó en esta misma cuadrícula para la selección de género de los hijos, que fueron favorecidos por el trabajo y el dinero que podían proporcionar a sus familias, así como por continuar con el linaje familiar.  A continuación se muestra una ilustración de la cuadrícula del predictor de género chino:   Como ejemplo, una madre de 18 años que concibió un hijo en enero tendría un bebé femenino.  Para esta publicación, crearemos un microservicio orientado a un propósito que devuelva una predicción de género basada en los mismos criterios. La carga útil resultante para el ejemplo anterior aparecería como se muestra a continuación:   { "month": 1, "age": 18, "gender": "female", "errorMessage": null }  El microservicio utilizará Java y Spring Boot y empleará un Dockerfile de varias etapas para compilar el servicio y crear una imagen de Docker que pueda alojar las API de predicción de nacimiento.   El código para el servicio se puede encontrar en GitLab en la siguiente dirección:   https://gitlab.com/johnjvester/birth-predictor  Creación de un patrón reproducible usando planos de renderizado  He escrito sobre la plataforma __   __ en las siguientes publicaciones: Render   Dedique cero tiempo a DevOps con Render PaaS   La nube perfecta: AWS, GCP y Azure todo en uno  Para mis instancias personales que se ejecutan en Render, he usado el lenguaje de programación Go, sitios estáticos y una instancia de Postgres. Esta vez, escribí el servicio en Java/Spring Boot. Si bien aún no existe soporte nativo para Java, la plataforma Render incluye soporte para cualquier cosa que se ejecute en un contenedor Docker.  Dado que el servicio de predicción de nacimientos incluye un Dockerfile de varias etapas, quería ver lo fácil que es implementar un servicio basado en Docker en la plataforma Render. Sin embargo, noté la  y quería ver cómo funciona eso también.   Especificación de plano  ¿Qué es un Blueprint?  Un Blueprint es la implementación de Render de Infraestructura como código (IaC). IaC también es algo que agrupo en un concepto más amplio llamado "* como código". Las organizaciones que necesitan administrar una implementación de varios servicios o que tienen servicios que requieren muchas opciones pueden definir su infraestructura de Render (servicios, bases de datos y grupos de entornos) como código en un archivo render.yaml.  Usando el modelo de renderizado  Basándose en el ejemplo de Blueprint proporcionado  , pude crear rápidamente un Blueprint para mis servicios Spring Boot que se ejecutan a través de contenedores Docker:   aquí   services: - type: web name: restful-api-spring-boot env: docker region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443  A partir de ahí, personalicé los datos YAML para el servicio de predicción de nacimientos para actualizar la propiedad de nombre y agregar una propiedad de repositorio, como se indica a continuación:   services: - type: web name: birth-predictor env: docker repo: https://gitlab.com/johnjvester/birth-predictor region: ohio # optional (defaults to oregon) plan: free # optional (defaults to starter) branch: master # optional (uses repo default) numInstances: 1 # optional (defaults to 1) healthCheckPath: /actuator/health envVars: - key: SERVER_PORT value: 443  Esta información se almacenó en la raíz del repositorio   , en un archivo llamado   . Después de confirmar y fusionar este cambio, el servicio estaba listo para implementarse en la plataforma Render. birth-predictor render.yaml  Desde el Tablero de procesamiento, seleccioné   :  Nuevo | Opción de plano Luego, seleccioné el repositorio de predictores de nacimiento, que conecté a mi cuenta de GitLab usando las instrucciones encontradas  .    aquí Como estaba usando un Blueprint, todo lo que tenía que hacer era proporcionar un nombre de grupo de servicios para mi nuevo servicio:  Después de presionar el botón   , comenzó el proceso de implementación:  Aplicar Unos minutos más tarde, el servicio se implementó sin ningún problema:   Predictor de nacimiento en acción  Con el servicio de predicción de nacimiento en ejecución, puedo emitir el siguiente comando cURL para obtener una nueva predicción:   curl --location --request POST 'https://birth-predictor.onrender.com/predict' \ --header 'Content-Type: application/json' \ --data-raw '{ "conceptionMonth" : 11, "conceptionAge" : 43 }'  La carga de respuesta resultante se ve así:   { "month": 11, "age": 43, "gender": "male", "errorMessage": null }  Esta información simplemente coincide con el mes de la concepción y la edad de mi esposa en el momento en que nuestro hijo (Finny) fue concebido. ¡En agosto de 2017 llegó!   Al igual que lo hicieron durante la dinastía Qing, pudimos confiar en el Predictor de género chino para pronosticar con éxito el sexo de nuestro hijo.  Conclusión  Desde 2021, he estado tratando de vivir de acuerdo con la siguiente declaración de misión, que creo que puede aplicarse a cualquier profesional de TI:   “Concentre su tiempo en ofrecer características/funcionalidades que amplíen el valor de su propiedad intelectual. Aproveche los marcos, productos y servicios para todo lo demás”.   -J. Vester  La especificación Blueprints de Render se adhiere a mi declaración de misión al permitir que los equipos de funciones y servicios se concentren en cumplir con los objetivos y metas establecidos, sin preocuparse por nada relacionado con DevOps.  Una vez que el servicio, el componente o la aplicación están listos, los equipos simplemente deben incluir el archivo render.yaml en la raíz de su repositorio y luego crear un nuevo servicio en la plataforma Render usando la opción Blueprint. En el futuro, cualquier actualización del repositorio conectado se implementará automáticamente minutos después de enviar el código a la rama indicada.  La plataforma Render vive con una mentalidad Zero DevOps, que es evidente en el origen del concepto Blueprint. Los desarrolladores de funciones y servicios quieren, y deben, centrarse en ofrecer actualizaciones y funcionalidades que brinden el máximo valor a sus partes interesadas. Render realmente entiende esta realidad.  Estoy seguro de que las palabras de moda siempre serán parte del espacio tecnológico. Sin embargo, comprender y adoptar la verdadera intención detrás de esas palabras de moda es algo que espero que los tecnólogos busquen.  Si está interesado en el código fuente de esta publicación, puede encontrarlo en GitLab en la siguiente dirección:   https://gitlab.com/johnjvester/birth-predictor  ¡Que tengas un gran día!

Super

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Diseño de microservicios con propósito

Diseño de microservicios con propósito

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps